The present invention relates to the delegation of rights in a distributed computing system. More particularly, the present invention relates to delegation through a chain or tree of deputies in the distributed system.
Distributed computing systems are becoming increasingly useful and prevalent. Distributed computers are connected by local area networks, wide area networks, and networks of networks, such as the Internet. These distributed computing systems make available platform-neutral, mobile code environments which contain a growing collection of computational objects, applications, data, and other information in the form of files, databases, images, and/or other named resources.
With the growth of such distributed computing systems and their information content, there is an urgent need to support the efficient and effective delegation of rights across heterogeneous systems, services, and platforms. Powerful and convenient delegation services are needed to achieve seamless distribution of critical resources, and to make the power of computing resources available for more widespread use. Ideally, delegation services help users (both human and digital) put computational tasks to work at times and locations which are appropriate for execution of those tasks and with access to required resources, without creating unacceptable security risks.
Various approaches have been taken to the problem of providing effective and efficient delegation services in a distributed computing system. For instance, a Simple Distributed Security Infrastructure (xe2x80x9cSDSIxe2x80x9d) has been designed to facilitate the construction of secure systems by providing terminology for defining access control lists and security policies. SDSI is also an attempt to move away from identity-based certification and towards a system based on roles and credentials. The SDSI system is key-centric. Rather than attach a public key to an identity, SDSI entities are the keys themselves. That is, SDSI principals are public keys that can make declarations by issuing verifiable signed statements. The statements may be made in the form of certificates which bind identifying information to a principal, assert that a principal does or does not belong to some group, and/or bind a name to a value such as a principal.
The Calypso architecture described by Tuomas Aura and other researchers from Helsinki University of Technology also uses a key-oriented approach. A public cryptographic signature key represents the entity that holds the corresponding private key. Key-oriented certificates are used to delegate rights. Access rights are delegated directly from key to key without explicitly identifying the involved entities by name in the certificates. Delegation is also transitive. That is, if Alice""s key authorizes Bob""s key to use a service and Bob""s key in turn authorizes Charlie""s key to use the service, then the system considers that situation to be equivalent to having Alice""s key delegate rights directly to Charlie""s key.
Although key-centric approaches can be useful, they assume it is not necessary to expressly associate a name (such as a user name or an account number) with a particular act of delegation. However, such associations can be very useful in assigning responsibility. Key-centric approaches also require a homogeneous environment if delegation is to be transitive. By contrast, identifying and distinguishing between entities in a chain of delegations allows both delegation between heterogeneous systems and persistent delegation, as explained in the description of the present invention below.
The concept of authentication is related to the concept of delegation. For instance, one way for a task A to delegate rights to a task B is for A to provide B with authentication information that allows B to impersonate A. This approach to delegation is relatively easy to implement but it also has serious disadvantages. Task B receives all rights of task A, including rights B does not necessarily need to perform the job at hand. Moreover, giving two tasks the same identity makes it harder to assign responsibility for inept or malicious acts which are performed under that identity.
A detailed approach to authentication in a distributed computing system is described in Network Working Group Request for Comments 1507 (xe2x80x9cRFC 1507xe2x80x9d), entitled xe2x80x9cDASS: Distributed Authentication Security Servicexe2x80x9d. As stated in RFC 1507, xe2x80x9cthe goal of authentication is to reliably learn the name of the originator of a message or request. The classic way by which people authenticate to computers (and by which computers authenticate to one another) is by supplying a password. There are a number of problems with existing password based schemes which DASS attempts to solve. The goal of DASS is to provide authentication services in a distributed environment which are both more secure (more difficult for a bad guy to impersonate a good guy) and easier to use than existing mechanisms. In a distributed environment, authentication is particularly challenging. Users do not simply log on to one machine and use resources there. Users start processes on one machine which may request services on another. In some cases, the second system must request services from a third system on behalf of the user. Further, given current network technology, it is fairly easy to eavesdrop on conversations between computers and pick up any passwords that might be going by. DASS uses cryptographic mechanisms to provide xe2x80x98strong, mutualxe2x80x99 authentication. Mutual authentication means that the two parties communicating each reliably learn the name of the other. Strong authentication means that in the exchange neither obtains any information that it could use to impersonate the other to a third party.xe2x80x9d
DASS operates by providing a global identity which allows a user to log into a network instead of requiring separate logins for each server. The user is assigned a name from a global namespace and that name will be recognized by any node in the network. A resource may be configured for access only by a particular user through a particular node, but the user is still known by the given global identity.
It would be an advancement in the art to provide an improved distributed computing system delegation service which expressly identifies the entities involved in a delegation of rights but does not require a global namespace.
It would be a further advancement to provide such an improved service which supports delegation across network boundaries.
It would also be an advance to provide such an improved service which is compatible with existing public key infrastructures and existing authentication tools and techniques.
Such delegation improvements are disclosed and claimed herein.
The present invention provides Distributed Deputization Points for use in a distributed computing system. Deputization is a particular type of rights delegation which expressly identifies the entities involved in the delegation and does not inherently require a global namespace. xe2x80x9cRightsxe2x80x9d are sometimes referred to in connection with xe2x80x9cpermissionsxe2x80x9d; the two terms are used interchangeably herein. In one embodiment, the invention operates as follows.
A user logs in and sends an authentication request to one of the Distributed Deputization Points (xe2x80x9cDDPsxe2x80x9d). The xe2x80x9cuserxe2x80x9d may be a user task for a human who is using the system, or it may be a system task which is created by the system software or by some application program. Login might be unnecessary for system tasks. The authentication request identifies the user by a user name, a user ID number, or the like. Familiar or novel authentication mechanisms may be used, including biometric readings, a smart card, and so on. The authentication request may include a logon certificate, a password, or another credential to prove that the user has the right to operate under the specified user name or user ID.
Assuming the credential and/or other authentication information is accepted by the DDP as legitimate, the user receives an authentication response. The authentication response includes an indication that the user is now authenticated, and may also include a credential identifying the permissions granted to the user as a result of the authentication. As noted, tasks created by the distributed computing system may also authenticate themselves to a DDP. In particular, deputized agents previously created by or on behalf of a DDP can in turn authenticate themselves to the same or another DDP in order to create additional deputies.
The authenticated user then sends the DDP a deputy credential request. The deputy credential request may contain the public key of the proposed deputy, or it may identify the deputy so the DDP can request the deputy""s public key from a repository in a public key infrastructure. Alternatively, the DDP may be responsible for seeing that a deputy is created and for obtaining the identity of the deputy from the operating system. When the user identifies the deputy, the deputy credential request also contains the private key of the proposed deputy encrypted with the user""s public key and a user credential which identifies the user and proves it is authorized to create deputies.
The maximum life span of the deputization or another expiration event may also be provided to the DDP by the user, or the DDP may use a default event or even override the event requested by the user. In some versions, no maximum life span or other predefined expiration event is specified and each right granted through a deputization is recognized until it is expressly revoked.
The permissions to be granted to the deputy may be specified to the DDP by the user. These permissions must be the same as, or a proper subset of, the permissions held by the user. The DDP can be configured to override the permissions requested by the user if system administrators determine that is appropriate. If the deputy credential request does not specify the deputy permissions, the DDP may use a default value or simply make the permissions the same as the user""s.
In response to the deputy credential request, the DDP creates a deputy credential. The deputy credential contains the user identity, permissions being delegated by the user, the private key of the deputy encrypted with the user""s public key, a deputy certificate, and the DDP""s digital signature. The deputy certificate contains the public key of the deputy in a certificate minted by the DDP or some other well-known DDP, deputy credentials from the DDP, deputy permissions, and the DDP""s digital signature. The deputy certificate may also contain a maximum deputy certificate life span that indicates when the deputization expires. Passage of time is not the only event that can trigger an expiration. Other deputization expiration events include, for instance, decommissioning an employee through the Human Resources department, an explicit or forced expiration by an administrator, or a database corruption event.
A user may have zero or more deputies, and each deputy may have zero or more individually deputized functions or deputies. Including the user identity in the deputy credential ensures that the user can be held responsible for the activities of its deputies. Including the private key of the deputy encrypted with the user""s public key allows the user to sign deputized functions in a way that makes it possible to trace the actions of both a particular user and a particular deputy in order to hold the correct party responsible for the activities of a given deputized function. The DDP signatures make it possible to hold the DDP involved responsible, and also make it possible to detect alterations in the deputy certificate and/or the deputy credential after the credential and certificate are provided by the DDP. The deputy permissions specify what the deputy can and cannot do, and the deputy credentials show that the permissions are accurate.
The user can deputize functions with the deputy credential. Each deputized function includes some code or script to run, the deputy certificate, and a signature created using the deputy""s private key (which is known to the user). A deputized function may also specify which permissions are being granted. Permission specification is not needed if the deputized function is going to run under the domain of the deputy, that is, with the same permissions as the deputy. Otherwise, the deputized function becomes a deputy itself and must be authenticated at the target with a deputy credential which specifies the permissions. Any access point that can authenticate the deputy certificate can authenticate the deputized function, allowing it the permissions specified in the deputy certificate. Multiple deputy certificates can be associated with a single deputized function or other deputy, in which case the permissions allowed are the union of the permissions in whatever individual deputy certificates are authenticated.
Unlike key-oriented approaches to delegation, deputization associates particular acts of delegation with particular entities and does not require a global namespace. Creating deputies in this manner has several advantages. Entities responsible for particular actions can be more readily identified. A delegation of authority can be made to persist even after the entity which delegated the authority logs off the system, since the deputy can persist. Delegations can also be made from one namespace to another, and across heterogeneous network boundaries, by creating deputies in the target namespace and/or network. Other features and advantages of the invention will become more fully apparent through the following description.